1. Field of the Invention
Exemplary embodiments of the present invention relate to software diagnostics, and more particularly, to diagnostics for the interactions between objects in a complex software system.
2. Description of Background
A software system is a system based on software components that form part of a computer system, which is a configuration of functional units (that is, hardware, software, firmware, resources, etc.) according to their nature, number, and chief characteristics. The details of a configuration, including how software systems are implemented therewithin, affects system function and performance. A software component is a system element that offers a predefined service and is able to communicate with other components. Software systems, which can be very large and complex, are typically described in terms of software architectures that specify the software components comprising the systems, the externally visible properties of those components, and the interactions or relationships between those components.
Object-oriented design is a software engineering methodology in which a software system is modeled as a group of interacting objects, rather than a collection of procedures. Each object in an object-oriented system is characterized by its class, state (that is, data elements), and its behavior, and encompasses encapsulated data and procedures that are grouped together, along with an ‘object interface’ that defines how to interact with the object, to represent some independent entity having a distinct role or responsibility in the system being modeled. Thus, an object-oriented software system is described by the interaction between the objects, and the behavior of the system results from the collaboration of the objects.
As the complexity of software systems increases, so too does the difficulty of identifying the source of failures in the system. Software failures are caused by errors (also known as bugs) that prevent the system from behaving as intended. Many bugs arise from oversights and errors made during design, coding, and data entry. Bugs can have a wide variety of effects, with varying levels of inconvenience. While some bugs may have only a subtle effect on a system's functionality and thus lie undetected for some time, more serious bugs may cause the system or applications running within the system to crash or freeze, leading to a denial of service.
The objects in an object-oriented software system are typically designed and tested for bugs either individually or in small groups during deployment. Nevertheless, this level of testing fails to consider any implementation constraints that might exist, such as concurrency, distribution, persistence, how the system is to be built, or how the system is to be implemented in different computing configurations, and, as a result, is generally insufficient to capture integration errors, performance problems, and other system-wide issues that result from the complex interactions between different objects in large, software systems implementing multitasking or other forms of concurrency control, such as operating systems or database systems. Often, rather than simply arising from individual problems with the objects themselves, many more complex bugs arise from unintended interactions between different objects in a software system. Computer program code can be complex—millions of lines long in some cases—often having been programmed by many people over a great length of time, so that programmers are unable to mentally track every possible way in which objects can interact. Furthermore, software systems tend to increase in complexity as they evolve over time (for example, due to additions and/or deletions of objects), and software systems are sometimes deployed in configurations in a manner that is different from what was originally planned and for which testing was performed.
Bugs that can arise from unexpected consequences of the interactions between objects of a software system are not captured during the initial testing of the objects and will only manifest during runtime. For instance, in a system that comprises a set of objects for which no errors were identified during testing, unforeseen problems related to interactions between the objects such as boundary conditional exceptions and failures relating to timing, load, and configuration mismatch issues may still arise. Presently, however, it is a challenge to reliably correlate and/or diagnose failures that occur in software systems as a result of the interactions between objects. This is especially challenging because of the complexities involved in reproducing these types of problems, as reproduction is a typical first step in locating a bug. For instance, even if a system executes the same sequence of operations that had previously caused a failure a second time, the timing of events during the second execution of these operations may vary in a way such that the underlying error does not affect performance of the system.